Universal patching machine

ABSTRACT

A universal patching machine is used to provide security for a computer system. A conversion function is generated for the patching machine that modifies input data to the computer system so that the computer system has an output and state that match the output and state that would be produced by a vendor-patched version of the computer system. The universal patching machine detects security vulnerabilities in intercepted data traffic. If a vulnerability violation is detected, the universal patching machine modifies the data traffic to remove the violation. Fixing the data traffic in this way ensures that the vulnerability cannot be exploited in an attack against the data network. The universal patching machine is formed from patch processors and a packet controller. The patch processors are formed from network patches. In operation, the patch processors detect vulnerabilities and issue modification commands that direct the packet controller to fix the data traffic.

This application is a division of patent application Ser. No.11/029,098, filed Jan. 3, 2005, which is hereby incorporated byreference herein in its entirety.

BACKGROUNDS OF THE INVENTION

This invention relates to computer security, and more particularly, toapplying patches to fix security vulnerabilities.

Security vulnerabilities in deployed software are discovered withregularity. Both operating systems and application software areaffected. As vulnerabilities are identified by the computer securitycommunity, they are often included in a list of common vulnerabilitiesand exposures (CVE). The CVE list attempts to standardize the names ofknown vulnerabilities.

Computers in which vulnerabilities are not addressed become exposed tosecurity risks. Often these risks are intolerable, so it becomesnecessary to install security patches. Patches (also sometimes called“updates” or “bug fixes”) are used to fix the portion of the softwarethat gave rise to the security vulnerability. When appropriate patchesare in place, the security risk associated with the vulnerability isreduced or eliminated.

In modern computer system environments, patch management can beexceedingly complex. In a typical business enterprise, there are oftenhundreds or thousands of networked computers, each with a potentiallydifferent software configuration. As a result, it is practicallyimpossible to test new patches exhaustively. System administrators arereluctant to install patches without testing, particularly on criticalmachines, so in practice many patches are not installed or are notinstalled in a timely fashion. This leaves many computer systems at riskof attack.

It is therefore an object of the present invention to provide improvedtechniques for applying security patches to computer systems.

SUMMARY OF THE INVENTION

A universal patching machine is provided that protects data networksfrom security vulnerabilities. The universal patching machine may beimplemented on a network appliance located at the edge of a datanetwork. In this location, the universal patching machine and networkappliance can intercept data traffic flowing between a communicationsnetwork such as the internet and the data network. The universalpatching machine modifies the intercepted data traffic so that thevulnerabilities cannot be exploited by an attacker.

The universal patching machine is formed from patch processors and apacket controller. The patch processors work at higher network layerssuch as network layers 6 and 7, whereas the packet controllers operateat lower network layers such as network layers 3-5.

The patch processors and packet controller work together to efficientlydetect vulnerability violations and modify data traffic where needed.Efficient processing is ensured by bypassing the higher-network-layerprocessing of the patch processors when the vulnerability violationdetection and fixing operations of the patch processors are not needed.These bypassing operations may be performed using the packet controller.

The patch processors are formed from network patches that addressvarious different security vulnerabilities. As new vulnerabilities arediscovered, the functionality of the universal patching machine isupdated. The update process involves identifying the vulnerabilitiesthat require attention and determining which network patches are neededto detect and fix these vulnerabilities. The universal patching machineis updated using these network patches.

Each network patch includes state machine logic and one or moreassociated vulnerability violation detection and fixing functions. Toensure efficiency, duplication is avoided when combining the statemachine logic of the network patches. The universal patching machine mayhave machine code libraries of helper functions. These helper functionsmay be used to merge the state machines of network patches into aunified state machine. During the formation of the unified state machinefor the patch processors, the overall size of the state machine logic isreduced.

As the capabilities of the universal patching machine are updated byadding or removing network patches for the unified state machine in realtime, the flow of data traffic through the universal patching machine isnot disrupted. With one arrangement, disruption to the data flow isavoided by handling old data traffic sessions with an old version of theuniversal patching machine processes and new data traffic sessions witha new version of the universal patching machine processes. With anotherarrangement, data traffic disruption is avoided by selecting a point intime at which to switch over to the new network patches that does notaffect the handling of the data traffic by the universal patchingmachine.

Further features of the invention, its nature and various advantageswill be more apparent from the accompanying drawings and the followingdetailed description of the preferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a diagram showing the behavior of a patched computer systemto an illustrative input.

FIG. 1B is a diagram showing how a universal patching machine alters theinput applied in FIG. 1A in accordance with the present invention.

FIG. 2 is a flow chart of illustrative steps involved in using auniversal patching machine to provide security for an unpatched computersystem in accordance with the present invention.

FIG. 3 is a diagram of an illustrative system in which a networkappliance is used to implement a universal patching machine forprotecting a computer network in accordance with the present invention.

FIG. 4 is a diagram of an illustrative network appliance showingcomponents that may be used to apply security patches in accordance withthe present invention.

FIG. 5 is a diagram showing how a universal patching machine may handlean illustrative vulnerability related to authentication evasion inaccordance with the present invention.

FIG. 6 is a diagram showing how a universal patching machine may handlean illustrative buffer overflow vulnerability in accordance with thepresent invention.

FIG. 7 is a diagram showing how a universal patching machine may have anumber of associated patch processors in accordance with the presentinvention.

FIG. 8 is a diagram showing how network patches may each have anassociated state machine and a function for detecting and fixing avulnerability violation in accordance with the present invention.

FIG. 9 is a diagram showing how a unified state machine and associatedvulnerability processing functions may be constructed from multiplenetwork patches in accordance with the present invention.

FIG. 10 is a diagram showing how the universal state machine andassociated functions are enlarged upon addition of a new network patchin accordance with the present invention.

FIG. 11 is a diagram showing how the universal state machine andassociated functions are reduced in size upon removal of an old networkpatch in accordance with the present invention.

FIG. 12 is a flow chart of illustrative steps involved in using theuniversal patching machine to enhance security for a computer system inaccordance with the present invention.

FIG. 13 is a flow chart of illustrative steps involved in maintainingup-to-date network patches for the universal patching machine inaccordance with the present invention.

FIG. 14 is a diagram showing how the state machine logic of typicalnetwork patches overlaps in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention relates to methods and apparatus for enhancingsecurity in a computer system by detecting and fixing securityvulnerabilities using patches.

The invention may be used in the context of any suitable computersystems. Environments in which security vulnerabilities are handled byinstalling software directly on a host computer are said to be“host-based.” Environments in which security vulnerabilities are handledby installing software on a network appliance at the edge of a computernetwork (e.g., on a network appliance that serves as a gateway to alocal area network), are said to be “network based.” In general, theinvention applies to both host-based and network-based environments. Forclarity, the discussion of the present invention sometimes focuses onnetwork-based environments.

One way to address security vulnerability violations is by installingpatches provided by a software vendor (e.g., the vendor of the operatingsystem and/or application software running on a particular machine ornetwork). When vendor patches are installed on a computer system, thesystem may be said to be a vendor-patched computer system. Anillustrative vendor-patched computer system 200 is shown in FIG. 1A.

Installing vendor patches to patch computer system 200 can be difficult,because of issues associated with testing, etc. In accordance with thepresent invention, a so-called universal patching machine (UPM) is usedto intercept and modify traffic, so that the behavior of an unpatchedcomputer system will be exactly or at least approximately the same asthe vendor patched computer system 200 of FIG. 1A.

A system 206 having a universal patching machine 202 and an unpatchedcomputer system 204 is shown in FIG. 1B. Universal patching machine 202may be implemented using any suitable hardware. For example, universalpatching machine 202 may be installed as part of a host-based securityarrangement or may be implemented on a network appliance that isseparate from the network 204 that is to be protected.

In the situation of FIG. 1A, an arbitrary input stimuli (inputX) tovendor-patched computer system 200 results in a corresponding output(output X) and a corresponding state (stateX). InputX representsarbitrary data traffic provided to the one or more computers of system200. OutputX represents the resulting output data produced by thecomputers of system 200. As an example, inputX may include a series ofweb page requests for a web server in system 200. OutputX may includethe web pages served by system 200 in response. StateX represents thestate of computer system 200.

The universal patching machine 202 of FIG. 1B is used to protect anunpatched computer system 204. The universal patching machine 202implements a conversion function F. The function F modifies datasupplied to input 208 to address security issues in unpatched computersystem 204. The input data that has been modified by conversion functionF is provided by the universal patching machine 202 at output 210.

If the input of FIG. 1A (inputX) is applied to input 208 of machine 202,the conversion functions produces modified data at output 210. Themodified data at output 210 is called inputX′, because output 210 servesas an input for unpatched computer system 204. When constructing theuniversal patching machine, a conversion function is selected thatattempts to make the universal patching machine 202 and unpatchedcomputer system perform exactly the same as vendor-patched computersystem 200. An exact match in performance is not always possible, but asuitable conversion function will generally be able to approximate theperformance of the vendor-patched computer system.

During operation of universal patching machine 202, the inputX tomachine 202 is converted by the conversion function F into inputX′, asshown in FIG. 1B.

In an exact match situation, when inputX′ is applied to unpatchedcomputer system 204, the output of system 204 is exactly the same asoutputX of FIG. 1A and the state of system 204 is exactly the same asstateX of FIG. 1A.

In an approximate match situation, it is not possible to identify aconversion function that will produce exact matches in output and state.Rather, the conversion function F produces an inputX′ that causes: 1.the output of system 204 to approximate outputX and the state of system204 to exactly match stateX or 2. the output of system 204 toapproximate outputX and the state of system 204 to approximate stateX.

Any suitable metric may be used to evaluate how close the output ofsystem 204 is to outputX and how close the state of system 204 is tostateX. As an example, a closeness function may be used to compute acloseness value that is then compared to a closeness threshold value.When a given output or state is close to outputX or stateX (e.g., belowthe threshold value), that output or state may be said to form anapproximate match.

As the example of FIGS. 1A and 1B demonstrates, the universal patchingmachine (UPM) intercepts data flowing to one or more unpatchedcomputers, and makes the behavior of the combined UPM and unpatchedsystem the same as a patched system.

For most vendor patches, it can be demonstrated that it is possible tofind an inputX′ and hence a suitable conversion function F that can beapplied to the unpatched system so that the output and state of system204 will be exactly the same as the output of patched system.

There are sometimes vulnerabilities for which it is not possible to findinputX′ and a conversion function F that produces exactly same state andoutput for unpatched system 204 as that of the patched system 200. Inthese cases, a suitable approximate conversion function F is identified.

Illustrative steps involved in generating and using conversion functionF to protect an unpatched computer system 204 are shown in FIG. 2.

At step 212, a suitable conversion function F is generated. Thegeneration operations of step 212 may be manual and/or automatic stepsperformed by a service provider associated with a universal patchingmachine service.

In an exact match situation, a conversion function F is generated atstep 214 such that the output and state of system 204 of FIG. 1B will bean exact match to the output (outputX) and state (stateX) of thevendor-patched system 200 of FIG. 1A.

If it is not possible to generate a conversion function F that willproduce an exact match in output and state, at step 216, a conversionfunction F is generated that produces an approximate match between theoutput of unpatched system 204 and the patched outputX of system 200(preferably a match that is as close as feasibly possible). It may ormay not be possible in this situation to identify a conversion functionF that simultaneously produces an exact match between the state ofunpatched system 204 and stateX of system 200. When possible, aconversion function F is generated such that, in response to input X atinput 208 of universal patching machine 202, the output of system 204 isan approximation to outputX and the state of system 204 is an exactmatch with stateX (step 216 of FIG. 2). If step 216 is not possible, aconversion function F is generated such that, in response to input X atinput 208 of universal patching machine 202, the output of system 204 isan approximation to outputX and the state of system 204 is anapproximation to stateX (step 218 of FIG. 2). Any suitable metric may beused to gauge the effectiveness of the approximations of outputX andstateX that are achieved by the conversion function.

Once a suitable conversion function for the universal patching machine202 has been generated at step 212, the conversion function is used tochange input data supplied to the universal patching machine such that asuitable corresponding input may be provided to the unpatched computersystem 204. By intercepting and modifying the input data with universalpatching machine 202, the approach of FIG. 1B may be said to involvepatching the traffic, rather than patching the system 204.

For vulnerabilities where it is not possible to find an inputX′ andhence a conversion function F that will produce exactly the same stateand output for the unpatched system 204 as that of a correspondingvendor-patched version of the system, a suitable conversion function canbe generated using the following approach:

In a first operation, generate a conversion function such that theresulting state of the unpatched computer 204 is same as the state ofpatched system 200 when the same input is applied to both systems. If itis not possible (feasible) to identify such a conversion function, aconversion function is identified that will not alter the state ofunpatched system 204.

In a second operation, modify the conversion function identified in thefirst operation such that the impact on the state of unpatched system204 will be same as described in the first operation, but the distance(difference) between the output data of the unpatched computer andpatched computer will be minimized. The distance (as calculated usingany suitable metric) between these respective outputs may be computedafter removing latency-related differences from the outputs.

These techniques for generating a suitable conversion function F for theuniversal patching machine 202 are further illustrated by the followingexamples.

A first example illustrates how a conversion function F may beidentified that produces exact matches in output and state for system204. This first example concerns the ASP.NET vulnerability. The ASP.Netvulnerability has revealed that an attacker can evade authentication byreplacing the forward slash character “/” with a backward slashcharacter “\” in a request directed to an IIS server in a computersystem. For this vulnerability, a vendor-supplied patch replacesbackward slash characters “\” with “/” characters in each URI (UniformResource Identifier) sent to the server. For this vulnerability, theconversion function will also change the “\” characters to “/” characterin HTTP URIs directed to the IIS server. This conversion function willchange every URI (inputX) such that the state and output of theunpatched system 204 will be same as the state and the output of thepatched system 200.

A second example illustrates the generation of a conversion function forthe universal patching machine that serves to produce an output forunpatched system 204 that is approximately the same as outputX ofvendor-patched system 200. This example concerns the CAN-2003-081vulnerability. In this vulnerability, a multi-threaded race condition inthe Windows RPC DCOM functionality with the MS03-039 patch installedallows remote attackers to cause a denial of service (crash or reboot)by causing two threads to process the same RPC request. This causes onethread to use memory after it has been freed. The vendor patch for thisvulnerability fixes the race condition so that the RPC DCOM service doesnot make the memory corrupted. The universal patching machine conversionfunction for this vulnerability will rate control (rate limit) theinputs such that two threads are never processing the same RPC request.This conversion function will stop the RPC service from corrupting thememory. The resulting output of the un-patched computer system will havesame values as that of a patched computer, but it will be delayed due tothe rate limiting introduced by the conversion function. The output ofsystem 204 is therefore a close approximation to outputX.

A third example concerns the CAN-2003-0352 vulnerability Thisvulnerability is the RPC/DCOM vulnerability that was exploited by theBlaster worm. Only 32 bytes were allocated for a filename field in theRPC API and the API did not check the filename length before copying thedata for the associated file. The vendor patch for this vulnerabilityincreases the memory buffer to 256 bytes and checks whether the inputfield is more than 256. If yes, the patched system will reject therequest. If the request has a filename field less than 256 bytes, therequest will succeed. If the length is more than 256 bytes, the requestwill be rejected. As described in connection with step 218, it is notpossible (in this example) to find a conversion function that willguarantee that the state of the unpatched computer will be same as thestate of vendor-patched computer. A suitable conversion function forthis vulnerability will truncate the filename field to 32 bytes. Theresult of this conversion function will be that the RPC service willreject a request if its length is more than 32 bytes, but will produceno change in state for the RPC service for requests where filename ismore 32 bytes. Both the state and output of the system 204 in this thirdexample are therefore approximately (but not exactly) the same as theoutputX and stateX of system 200 in response to an identical inputX.

For the universal patching machine 202 to be able to examine all of theinputs destined to an application or operating system, machine 202should generally be deployed as close as possible to the unpatchedsystem 204. A host-based universal patching machine 202 will have fullvisibility into all of the inputs, but such a universal patching machinewill also exhibit the types of limitations generally seen in host-basedintrusion prevention systems such as difficulties associated withproduct management and deployment.

Network-based UPM (NUPM) solutions have visibility only into networktraffic and hence can address only network (or remote) vulnerabilities,but have advantages in terms of ease of management and deployment.

An illustrative network-based UPM system 10 in accordance with thepresent invention is shown in FIG. 3. In the illustrative arrangement ofFIG. 3, a computer network 12 is protected from security vulnerabilitiesby a network-based universal patching machine 20 implemented on anetwork appliance 18. In a typical scenario, an entity at a computeroutside of network 12 such as one of computers 24 desires to communicatewith an entity at a computer 14 inside network 12 over a communicationsnetwork 22. Network appliance 18 is shown as being separate from network12 in FIG. 3, but because network appliance 18 may be operated andinstalled by a system administrator associated with network 12, networkappliance 18 is sometimes referred to as being part of network 12 or isreferred to as being located at the edge of network 12.

Network appliance 18 may be based on any suitable computer hardware. Atypical network appliance 18 has a CPU, memory, hard disk storage, andcommunications ports. The communications ports may be used to receiveand transmit incoming and outgoing data traffic. Communications portsmay also be used to support communications between appliance 18 and abackup appliance to provide redundancy in the event of an equipmentfailure. The processor, memory, and storage in network appliance 18 maybe used to run software for implementing the functions of universalpatching machine 20. Software may be provided to appliance 18 using anysuitable arrangement. For example, some software may be provided toappliance 18 when appliance 18 is installed. Other software 18 may bedownloaded from a service provider. As an example, a service provider ata computer 24 may deploy network appliance 18 at the premises of acustomer's network 12. Through remote access procedures, the serviceprovider may contact appliance 18 to set up and/or update thefunctionality of appliance 18 with a current set of network-basedpatches as needed. If desired, contact may be initiated by the networkappliance. To enhance processing throughput, some or all of thefunctionality of the universal processing machine may be implementedusing dedicated hardware. For example, universal processing machinefunctions may be implemented using custom hardware components such ascustom boards, custom field-programmable gate arrays (FPGAs), andapplication-specific integrated circuits (ASICs). For example, we areplanning to implement a packet controller may be implemented usingcustom hardware.

Computers 14 and 24 may be any suitable computing equipment such asmainframe computers, workstations, portable and desktop computers,handheld computers, etc. Communications network 22 may be any suitablenetwork such as one or more local area networks, the internet, etc. Thecomputers of network 12 may be interconnected by wired and wirelesscommunications paths 16. Typical network communications paths includeEthernet cables, fiber-optic paths, wireless network nodes, etc. Anysuitable network topology and network equipment may be used tointerconnect the computers 14 in network 12. Moreover, network 12 may bea local area network, a metropolitan area network, a wide area network,or any other suitable network. Generally network 12 will be associatedwith an organization that desires to protect its assets through properdeployment of security patches.

Network appliance 18 intercepts data traffic sent to and from network12. The data traffic to and from network 12 may be any suitablecommunications traffic. For example, the data traffic may be webtraffic, email traffic, or any other suitable data traffic.

In a typical scenario, a user at a computer 24 requests a web page froma web server 14 in network 12. In this type of environment, the user'sinternet browser or other suitable client software generates an httprequest and transmits this request to an appropriate web server 14 atnetwork 12. In response, the web server 14 at network 12 retrieves therequested page and provides it to the user. The incoming traffic tonetwork 12 includes the http request from the user. The outgoing trafficfrom network 12 includes the web page material that is provided to theuser in response to the request.

Both incoming and outgoing data traffic may be intercepted by thenetwork appliance 18. If the network appliance 18 detects a securityvulnerability violation associated with the data traffic, the datatraffic may be altered to overcome the vulnerability. In this way, thenetwork appliance 18 may be said to patch or fix the data traffic,rather than directly patching the computers in network 12 by installingvendor patches. This method can be used to provide network patch for allremote vulnerabilities. Because the arrangement of FIG. 3 separates thepatching operations of network appliance 18 from the various hardwareand software platforms associated with the computing equipment 14, asingle network appliance 18 can be used to provide security for multiplecomputers 14. This greatly reduces the complexity associated withproviding security for the computers 14.

FIG. 4 shows an illustrative architecture that may be used to implementthe network-based universal patching machine 20. The arrangement shownin FIG. 4 is merely illustrative. Any suitable arrangement may be usedto provide the functions of universal patching machine 20 if desired.

As shown in the example of FIG. 4, the universal patching machine 20 mayhave a packet controller 26 and patch processors 28. Packet controller26 examines data packets in the traffic flowing through patching machine20. Packet controller 26 outputs all packets from universal patchingmachine 20 that are believed to be free of vulnerability issues. Packetcontroller 26 redirects packets that are associated with possiblevulnerability violations to patch processors 28. Patch processors 28work with packet controller 26 to detect and fix vulnerabilityviolations.

Packet controller configuration data 30 and patch processorconfiguration data 32 may be used to support the operations of packetcontroller 26 and patch processors 28. Configuration data 30 and 32 mayinclude settings and executable code.

Patching machine 20 intercepts inbound and outbound traffic associatedwith network 12 (FIG. 3). As data passes through patching machine 20,patching machine 20 detects and fixes security vulnerabilities. If, forexample, patching machine 20 determines that incoming data for a webserver 14 in network 12 includes an http request and if there is asecurity vulnerability related to http requests, the patching machine 20can extract the request from the data being sent to the web server andcan alter the request so as to overcome the vulnerability. By patchingthe traffic in this way, it is not necessary to block potentiallylegitimate http requests.

Network communications functions are often described in the context of alayered network model. For example, networking protocols are oftendescribed with reference to the International Standard Organization'sOpen System Interconnect (ISO/OSI) network layer model. This model hasseven network layers: physical (layer 1), data link (layer 2), network(layer 3), transport (layer 4), session (layer 5), presentation (layer6), and application (layer 7). The physical layer relates to thephysical structure of network connections. The data link layer providescontext to the signals at the physical layer. In the data link layer,bits are assigned physical addresses and are formatted into frames.Functions such as error checking may be implemented at the data linklayer. At the network layer, data is packaged into datagrams. Thenetwork layer also handles the routing of datagrams from one network toanother. The transport layer handles operations involved in setting upconnections between machines. The transport layer supports flow controland multiplexing functions. The session layer manages communicationssessions using handshaking and other mechanisms. The presentation layerhandles operations such as data encryption and compression. Theapplication layer provides services for users.

To optimize the efficiency of the data processing tasks performed by theuniversal patching machine 20, it is generally preferred to perform asmuch processing as possible at lower layers in the network stack. Thistype of processing architecture is more efficient than an architecturein which data is processed only at high levels in the network layerstack.

In general, packet controller 26 handles the lower network layers (e.g.,layers 2-5). Patch processors 28 process traffic at higher layers (e.g.,layers 5-7). The packet controller 26 and patch processors 28 worktogether by issuing commands. In a typical scenario, the patchprocessors detect a vulnerability that needs to be addressed. The patchprocessors then issue a modification command to the packet controllerthat directs the packet controller to perform an appropriate datamodification operation. The modification command may, for example,direct the packet controller 26 to change, remove, or add a data packet.The modified data is not susceptible to the vulnerability and maytherefore be considered to be “fixed” or “patched.” After the datatraffic has been fixed by the patch processors 28 and packet controller26, it may be forwarded to its intended destination.

Packet controller 26 preferably receives and sends data in compliancewith all layer 2-4 communications protocols. As an example, packetcontroller 26 may support Ethernet at layer 2, Internet Protocol (IP) atlayer 3, and Transport Control Protocol (TCP) at layer 4.

Patches processors 28, which handle traffic at layers 5-7, use networkpatches to implement vulnerability detection and fixing functions. Thenetwork patches are used to form a unified state machine that implementsprocedures for universal patching machine 20.

Network patches may be added and removed as desired to modify theunified state machine. For example, a new patch may be distributed tonetwork appliance 18 from a service provider over communications network22 or a service provider may send commands to network appliance 18 thatdirect the network appliance 18 to remove an old patch from active use.

These changes may be performed in real time without disrupting the datatraffic. A system administrator, service provider, or other suitableentity may update the patches for the universal patching machine 20 onnetwork appliance 18 without rebooting or otherwise halting theoperation of the appliance 18. Data traffic flows continuously throughappliance 18, even as new patches are added and old patches are removed.

Patches are added by modifying the patch processor capabilities ofuniversal patching machine 20, without changing the operating system orapplication programs on the computers 14 in network 12. It is thereforenot necessary to attempt to test the operation of new patches for allpotential configurations of computers 14. The arrangement of FIG. 3therefore avoids the testing and downtime problems associated withconventional patching procedures.

Patch processor configuration data 32 contains software and data forsupporting the operation of patch processors 28. Patch processorconfiguration data 32 may, for example, contain machine code libraries(e.g., DLL's) for the network patches used by patch processors 28. Themachine code from these libraries can be assembled to form the unifiedstate machine for the patch processors 28. Patch processor configurationdata 32 may include system parameters that a service provider may adjustremotely over network 22. System parameter adjustments may be used tooptimize the performance of the universal patching machine 20.Illustrative system parameters include system parameters for controllingmemory usage in network appliance 18, parameters for setting thepermitted number of concurrent processing threads supported by networkappliance 18, etc.

Packet controller configuration data 30 includes data that informs thepacket controller 26 how to implement access policies. The accesspolicies may specify whether the packet controller 26 should output datafrom network appliance 18 without processing or should send data topatch processors 28. The access policies may use any suitable criteria.As an example, access policy determinations of whether to forward datato an output or to process data for vulnerabilities may be made based onIP address and port number information.

Packet controller configuration data 30 also preferably includes datathat informs the packet controller whether or not the packet controllershould forward data through network appliance 18 or should divert datato patch processor 28 based on whether the traffic is client traffic orserver traffic.

If desired, packet controller configuration data 30 may includeblock-size-to-skip data that indicates the size of blocks of data thatthe packet controller 26 should output from the network appliancewithout inspection. This setting may be adjusted in real time by thepatch processors 28. As an example, if the patch processors 28 detectthat the data traffic being handled by the network appliance 18 containsan email message with a large attachment and if the network appliance 18determines that the attachment is not associated with any potentialvulnerabilities, the patch processors 28 can adjust theblock-size-to-skip data in the packet controller configuration data 30appropriately. This adjustment will then direct the packet controller 26to forward the email attachment through network appliance 18 withoutinspecting its contents. Throughput efficiency is enhanced by directingpacket controller 26 to pass data that does not correspond to a securityvulnerability through network appliance 18 without patch processing.

The operation of universal patching machine 20 in handling twoillustrative vulnerabilities is shown in FIGS. 5 and 6. FIG. 5 shows howthe universal patching machine 20 processes an authentication evasionvulnerability called the ASP.Net vulnerability. FIG. 6 shows how theuniversal patching machine 20 processes a buffer overflow vulnerabilitycalled the CAN-2003-0352 vulnerability.

Network appliance 18 and universal patching machine 20 preferably handletwo-way data traffic.

In handling data traffic that is outbound from network 12, networkappliance 18 and universal patching machine 20 receive the outbound datatraffic at an input to the network appliance 18 that is connected tonetwork 12. The data is either forwarded in unmodified form to an outputof network appliance 18 that is connected to communications network 22(FIG. 3) or is provided to this output after processing by patchprocessors 28 (FIG. 4) to remove vulnerability violations.

In handling data traffic that is inbound to network 12, the networkappliance 18 and universal patching machine 20 receive the inbound datatraffic at an input to network appliance 18 that is connected to network22. The data from the input is either forwarded in unmodified form to anoutput of network appliance 18 that is connected to network 12 or isprovided to this output after processing by patch processors 28 (FIG.4).

In FIGS. 5 and 6, data that is being received at the input of thenetwork appliance 18 and universal patching machine 20 is shown asentering the diagram from the left. Data that is being provided to theoutput of the network appliance and universal patching machine 20 isshown as exiting the diagram to the right. In the diagrams of FIGS. 5and 6, data flow lines are superimposed on a representation of the sevennetwork layers (1-7) of the ISO/OSI network layer model.

The example of FIG. 5 relates to a vulnerability in which an attackercan send specially crafted requests to a server to view secured contentwithout providing proper credentials. Analysis of this vulnerability(the ASP.Net vulnerability) has revealed that the attacker can evadeauthentication by replacing the forward slash character “/”, with abackward slash character “\” in the server request. The universalpatching machine 20 handles this vulnerability by replacing occurrencesof any backslash character or its Unicode equivalent with a forwardslash character.

During processing, the universal patching machine 20 receives datatraffic flowing between network 22 and network 12. Packet controller 26examines the data traffic at layer 3, as shown by line 34 and test point36. In the illustrative example of FIG. 5, it is assumed that network 12of FIG. 3 contains an Apache web server 14 and a IIS web server 14without vendor patches. It is also assumed that Apache traffic is freeof vulnerabilities (in this example). The ASP.Net vulnerability onlyapplies to IIS web server traffic.

At test point 36, the packet controller 26 determines whether thetraffic is Apache traffic or is associated with the IIS server. Inmaking this determination, the packet controller 26 uses the accesspolicy information (e.g., an access policy list) in packet controllerconfiguration data 30 (FIG. 4).

In particular, the packet controller 26 examines the headers of thepackets in the data traffic to determine their associated IP address andport number. Based on the IP address and port information, the packetcontroller 26 determines whether the traffic is associated with theApache server in network 12 or the IIS server in network 12. If thetraffic is Apache traffic, it can be concluded (in this example) thatthere are no vulnerabilities associated with the traffic. The trafficmay therefore be forwarded directly to the output of the networkappliance 18 without modification, as shown by line 39. This allowshigher-layer processing of this data traffic to be avoided, whichincreases processing efficiency significantly.

If, at test point 36, the packet controller 26 determines that thetraffic is for the IIS server, the packet controller 26 can continue toanalyze the data traffic at network layer 4 (line 38) by performingadditional testing at test point 40. In particular, at test point 40,the packet controller 26 can determine whether the traffic that has beenreceived at the network appliance input is server traffic originating atthe IIS server 14 in network 12 or is client traffic originating at oneof computers 24. For the ASP.Net vulnerability, the vulnerability isrelated to the server requests made by the client to the IIS server, sotraffic from the server can be forwarded directly to the output of thenetwork appliance and patching machine, as shown by line 42.

If the packet controller 26 determines at test point 40 that the trafficis from the client, the packet controller 26 can pass the data trafficto the patch processors 28 (FIG. 4) for analysis at network layer 5, asindicated by line 44.

As indicated schematically by test point 46 of FIG. 5, the data trafficthat is passed to the patch processors 28 for processing at layer 5 isanalyzed by the patch processors to determine whether or not it shouldbe forwarded to the patching machine output at layer 5 without furtherprocessing. In this example, it is appropriate to forward the datatraffic to the patching machine output if it corresponds tochunk-encoded data, as indicated by line 48. If the data traffic is notchunk-encoded data, the patch processors 28 perform further analysis atlayers 6 and 7, as indicated by line 50 and box 52.

The forwarding of chunk-encoded data in FIG. 5 is merely an illustrativeexample. In general, blocks of data traffic may be forwarded to thepatching machine output at layer 5 without further processing at networklayers 6 and 7 by the patch processors 28 whenever it is determined thatdata traffic can be excluded from layer 6 and 7 processing because thatdata does not contain vulnerability violations. For example, the patchprocessors 28 may identify which blocks of data are to be forwardedwithout layer 6 and 7 processing using the results of a previous dataanalysis or by performing real-time data traffic analysis on headerinformation or other data stream contents. The patch processors 28 canspecify which blocks to forward using any suitable technique. As anexample, the patch processors can specify a block by its start locationand block size (e.g., the next N bytes of data starting at a particularlocation are to be forwarded without layer 6 or 7 processing). Asanother example, the patch processors can specify a block by its blockending pattern—data traffic in the block is forwarded without layer 6 or7 processing until the patch processors locate the specified endingpattern in the data traffic. These techniques allow potentially largeblocks of data to be forwarded without layer 6 or 7 processing, whichenhances efficiency.

In the example of FIG. 5, the patch processors 28 analyze the datatraffic during layer 6 and 7 processing operations to attempt to detectviolations of the ASP.Net vulnerability. In particular, processors 28attempt to locate a backslash in a server request for the IIS server 14in network 12. If a violation of the ASP.Net vulnerability is detected(i.e., if a backslash is located in the request data), the patchprocessors issue a corresponding modification command for the packetcontroller 26. As indicated by line 54, box 56, and line 58, the packetcontroller 26 receives the modification command from the patchprocessors 28, performs the requested modification operation on the datatraffic at layer 5 to remove the vulnerability violation and thereby fixthe traffic, and provides the corresponding modified (fixed) traffic tothe patching machine output. In this example, the modification requestspecifies that the packet controller should replace the backslash in theIIS server request with a forward slash. Fixing the data traffic in thisway before it reaches network 12 eliminates the security risk associatedwith the ASP.Net authentication evasion vulnerability, but does notblock legitimate server requests, many of which may include backwardslashes. The replacement of one character with another in response to amodification command is merely one illustrative example. In general,commands may be used to change one byte of data for another, may be usedto delete data, may be used to insert data, etc.

The example of FIG. 6 concerns the CAN-2003-0352 buffer overflowvulnerability. This vulnerability is an RPC/DCOM vulnerability that wasexploited by the so-called Blaster worm. RPC/DCOM is a service in theMicrosoft Windows Operating System that is used to support remoteprocedure calls. An attacker who exploits the CAN-2003-0352vulnerability may be able to run code on a computer without properauthorization. A successful attacker would therefore be able installsoftware or modify data on the attacked computer. Exploitation of thevulnerability requires that the attacker form a DCOM object activationrequest to the computer that contains a filename field greater than 16characters in length.

The CAN-2003-0352 vulnerability arose because only 32 bytes wereallocated for the filename field in the RPC API and no checks were maderegarding the length of the filename field before copying data. It wasassumed that a machine name would never be more than 16 characters.However, it is legal to use a DNS-style name that is longer than 16characters, such as \\server.subdomain.domain.com\share\etc. If a longmachine name (S2 name parameter) such as this is used by a user, theuniversal patching machine 20 fixes the vulnerability violation bytruncating the S2 name parameter to make it 32 bytes long. Thevulnerability violation is fixed, so a user's sessions will not bedropped without the user knowing the cause of the problem, as would bethe case if all uses of long machine names were blocked.

The operations taken by the universal patching machine 20 to detect andfix violations of the CAN-2003-0352 vulnerability are shown in FIG. 6.During operation, the universal patching machine 20 receives inbounddata traffic from network 22. Packet controller 26 examines the incomingdata traffic at layer 3, as shown by line 60 and test point 62. In theillustrative example of FIG. 6, it is assumed that the CAN-2003-0352vulnerability is the only vulnerability in existence.

At test point 62, the packet controller 26 determines whether thetraffic is destined for a computer 14 in network 12 that has alreadybeen patched with a vendor patch to prevent exploitation of theCAN-2003-0352 vulnerability. The packet controller 26 uses information(e.g., an access policy list) in packet controller configuration data 30(FIG. 4) in making this determination. For example, the packetcontroller 26 can examine the headers of the packets in the data trafficto determine their associated IP address and port number. The IP addressand port information and other information in configuration data 30indicates to the packet controller 26 whether the traffic is destinedfor a computer 14 that has been patched. If the traffic is for aRPC/DCOM-patched computer 14, the computer 14 is not susceptible tovulnerabilities, so it is not necessary to process the traffic furtherin universal patching machine 20 to remove vulnerability violations.Rather, the traffic can be forwarded directly to the output of thenetwork appliance 18 without modification, as shown by line 64. Thisimproves processing efficiency in universal patching machine 20, becausehigher-layer processing of the data traffic is bypassed. It also avoidsdouble patching.

If, at test point 62, the packet controller 26 determines that thetraffic is for a computer 14 that has not been patched to preventexploitation of the CAN-2003-0352 vulnerability, the packet controller26 analyzes the data traffic at network layer 4 (line 66) by performingadditional testing at test point 68. The CAN-2003-0352 vulnerabilityaffects server-bound traffic from a client such as one of computers 24(FIG. 3), but does not affect traffic bound for a client computer 14 innetwork 12. Accordingly, during the processing of test point 68, thepacket controller 26 determines whether the traffic that has beenreceived at the network appliance input is traffic from a server or istraffic from a client. Traffic from a server in network 12 is forwardeddirectly to the output of the network appliance and patching machine, asshown by line 70.

If the packet controller 26 determines at test point 68 that the trafficis from a client computer 24 in network 12, the packet controller 26 canpass the data traffic to the patch processors 28 (FIG. 4) for analysisat network layers 6 and 7, as indicated by line 72.

During layer 6 and 7 processing, the patch processors 28 analyze thedata traffic to attempt to detect violations of the CAN-2003-0352vulnerability. In particular, processors 28 attempt to detect an S2 nameparameter in the data with a length greater than 32 bytes. If a namegreater than 32 bytes long is detected, the patch processors 28 issue acorresponding modification command for the packet controller 26. Themodification command directs the packet controller 26 to truncate the S2name parameter in the data traffic so that the S2 name parameter is 32bytes long. The detection of the vulnerability violation and issuance ofthe modification command for the packet controller 26 is illustrated inFIG. 6 by box 74 and line 76. As indicated by box 78, the packetcontroller 26 performs the requested data modification (truncation) atlayer 5 to remove the vulnerability violation from the data traffic. Thefixed data traffic is then provided at the patching machine output, asshown by line 80. Because excess name parameter lengths are removed fromthe data traffic by the universal patching machine 20, it is notnecessary to block all traffic containing excessively long nameparameters.

As with the ASP.net example of FIG. 5, the use of universal patchingmachine 20 to handle the vulnerability violation is superior tosolutions based on blocking traffic, because patching machine 20 doesnot block legitimate traffic. Because traffic is not blocked byuniversal patching machine 20, attackers attempting to exploitvulnerability violations in network 12 will not know that a securitysystem is in place, but rather will conclude that system 12 has beenpatched for the vulnerabilities they are trying to exploit. Afterattempting to exploit a number of different vulnerabilities, they willbecome frustrated and move to a new target. In this type of situation,attackers will have left a large amount of forensic information behind,so that their activities may be tracked. With traffic blocking systems,in contrast, an attacker immediately becomes aware that an intrusionprevention system is in place and will use evasive techniques toovercome its protections.

The universal patching machine 20 fixes vulnerability violations usingnetwork patches (NPs) in patch processors 28. Network patches areconversion functions that are applied to network traffic destined to anunpatched operating system or application in network 12. The networkpatches modify the traffic so that the response of the unpatchedservices on the equipment 14 in network 12 behave exactly as if thoseservices had been patched using a conventional vendor patch. Because thenetwork patches operate in patch processors 28 in universal patchingmachine 20 on equipment 18, it is not necessary to implement any patchesfor the same vulnerability on the equipment 14 of network 12. Thenetwork patches in patch processors 28 therefore provide universalpatching without requiring the installation of vendor patches in apotentially vast number of diverse equipment configurations in network12. The network patches in patch processors 28 also fix vulnerabilitiesfor which no vendor patches are available.

In constructing the universal patching machine 20, the equipment innetwork 12 that needs the protection provided by network patching isprofiled. For each item of equipment 14, information is gathered onwhich services (operating systems and applications) are to be protected,which port numbers the services are running on, which patches fix remotevulnerabilities but have not yet been applied to the services, and whichremote vulnerabilities are not patched. This information is used by theuniversal patching machine 20.

As shown in FIG. 7, the patch processors 28 of universal patchingmachine 20 are each made up of a number of network patches (NPs) 82.There are M patch processors in FIG. 7. The N network patches 82 inpatch processor 1 are labeled NP₁₁ through NP_(1N). In general, theremay be a different number of network patches in each patch processor.The T network patches in patch processor M are labeled NP_(M1) throughNP_(MT). A separate patch processor 28 is used for each service to beprotected. For example, in a network 12 with an Apache web server, anIIS web server, a personal computer running the Windows XP operatingsystem, and a personal computer running the Windows 2000 operatingsystem, one patch processor 28 is used to protect the Apacheapplication, one patch processor 28 is used to protect the IIS machine,one patch processor 28 is used to protect the Windows XP computer, andone patch processor 28 is used to protect the computer on which Windows2000 has been installed. In general, one patch processor is used tosecure an application or a service with the similar patch level runningon multiple machines in the network 12. For example, machines running1.x version of Apache server will use a different patch processor 28than machines running the 2.x version of Apache server.

To reduce latency and to lower the processing requirements associatedwith implementing patch processors 28, the network patches 82 arepreferably merged into a unified processing engine. As shown in FIG. 8,each network patch 82 includes a state machine logic portion 84 and avulnerability detection and fixing function portion 86. Portions 84 and86 are provided as separate machine code files in patch processorconfiguration data 32 (FIG. 4). The state machine logic 84 of thenetwork patches implements a state machine that is used to parse thedata traffic for processing by functions 86. Functions 86 detectvulnerability violations in the data traffic and fix them.

In general, there are significant commonalities among the state machines84 of the network patches 82. In the universal patching machine 20, thestate machines 84 of the different network patches 82 are merged to forma unified state machine. The process by which multiple individualnetwork patches 82 are merged into a unified state machine 84 withmultiple associated functions 86 is shown in FIG. 9.

An example of an operation that may be shared among processors 28 is anextraction operation used when extracting a parameter from the datatraffic. This type of operation is used by many patch processors 28 asthey parse the data traffic. It therefore is helpful to share as much ofthe extraction functionality as possible between patch processors 28.The merging process of FIG. 9 is performed using helper functions(sometimes also called merging functions) that are contained in thepatch configuration data 32 whenever a new network patch is loaded foruse in unified patch processor 20 or an old network patch is removed.

During the merging process, the state machines 84 of the various networkpatches 82 are merged to form a single state machine. Duplicate statesare avoided and the overall size of the state machine logic iscompressed to minimize the total number of states. Significantperformance enhancements are obtained through the merging process,because duplication of state machine processing logic is avoided.

The helper functions used to construct the unified state machine logicand functions for the universal patching machine 20 can run withoutinterrupting the operation of the patch processors 28 and packetcontroller 26 in the universal patching machine 20. This allows networkpatches to be added for newly discovered vulnerabilities withoutdisrupting the operations of patching machine 20 and network appliance18. It also allows network patches for vulnerabilities that have beenpatched using vendor patches to be removed. The addition of new networkpatches and the removal of old network patches are operations that canboth be performed without causing any disruption in the flow of datatraffic or the vulnerability detection and fixing operations ofuniversal patching machine 20 when processing the data traffic.

FIG. 10 illustrates how the unified state machine 84 grows when a newnetwork patch is added. The state machine logic 84 of the merged networkpatches contains states that are common with the existing state machineof the patch processor. Only the states that are unique to the newnetwork patch 82 are added to the unified state machine. In the exampleof FIG. 10, new network patch NP_(NEW) contains a new vulnerabilitydetection and fixing function F_(NEW) 88, so the merged network patchesshown on the right side of FIG. 10 include both additional state machinelogic 88 and a new associated detection and fixing function 90. There isno commonality between the detecting and fixing functions used by thepatch processors 28, as each detecting and fixing function detects andfixes a specific vulnerability violation.

FIG. 11 shows how the state machine logic 84 of the patch processors 28shrinks when a network patch is removed. In the example of FIG. 11,network patch NP_(K) has been removed from the unified state machine 84,resulting in state machine logic 84 from which state machine logicportion 92 has been removed. The vulnerability detection and fixingfunction associated with network patch NP_(K) is function F_(K). Asshown on the right side of FIG. 11, when network patch NP_(K) is removedfrom the unified state machine 84, function F_(K) is removed from thepatch processors.

The process of removing network patch NP_(K) from the patch processorsthat is illustrated in FIG. 11 is performed by the helper functions ofpatch processor configuration data 32 (FIG. 4) without disrupting theoperation of the patch processors 28 or packet controller 26.

Any suitable technique may be used to ensure that the real timeprocessing of data traffic is not affected by the addition or removal ofnetwork patches.

With one suitable approach, the helper functions make a copy of theexisting state machine logic. The existing state machine logic is usedfor handling existing sessions in the data traffic. Before the new copyof the state machine logic is placed into use, the changes of FIG. 10and FIG. 11 are made by the helper functions. Once the new copy of theunified state machine logic has been modified (i.e., so that region 92and function F_(K) have been removed from the state machine in the FIG.11 example or so that region 88 and function F_(NEW) have been added inthe FIG. 10 example), the modified version of the new copy of theunified state machine logic is used to handle new communicationssessions in the data traffic. Because existing sessions are handled bythe unmodified state machine while the new sessions are handled by themodified state machine, no communications traffic is disrupted by theprocess of modifying the unified state machine.

With another suitable approach, the helper functions that are used toperform the unified state machine modification select a particular pointin time at which to make the modification. By selecting a point in timeat which the data traffic is not affected by the modification, themodification is made without disrupting the operations of the universalpatching machine 20.

A flow chart of illustrative steps involved in setting up and using theuniversal patching machine 20 to detect and fix vulnerability violationsis shown in FIG. 12. At step 94, the helper functions of patch processorconfiguration data 32 (FIG. 4) are used to form the unified statemachine 20, as described in connection with FIGS. 7-11.

At step 96, the patch processors 28 and packet controller 26 receivedata traffic at an input to network appliance 18. The data traffic thatis received may be inbound traffic that is destined to equipment 14 innetwork 12 or may be outbound traffic from equipment 14.

At step 98, the packet controller 26 and patch processors 28 are used todetect and fix vulnerability violations in the data traffic. During step98, the state machine logic 84 extracts the states of the layer 6 and 7protocols associated with the traffic, extracts contexts from thetraffic, and extracts necessary “information elements” (e.g., elementssuch as hostname and filename elements in the context of an httprequest, etc.).

Following processing, the data traffic is output at step 100. The packetcontroller 26 and patch processors fix detected vulnerabilityviolations, so that the outgoing traffic from the universal patchingmachine 20 does not contain vulnerability violations.

The universal patching machine 20 is implemented using a networkappliance 18 that is located between network 22 and the network 12 beingprotected. When a new network patch is injected into the universalpatching machine 20, the services being protected are not disrupted.FIG. 13 shows illustrative steps involved in setting up and maintainingthe patch processors 28 in an environment in which network patchrequirements for machine 20 evolve as a function of time.

At step 102, vulnerabilities that need to be addressed by the universalpatching machine 20 are identified. The vulnerability identificationprocess of step 102 may involve examining publicly available lists ofcommon vulnerabilities and exposures (CVE lists), consulting vendors forlists of vendor-announced patches, determining whether hackers or otherthird-parties in the software community have publicized vulnerabilities,or using other suitable resources. The process of step 102 may beperformed automatically (e.g., using software operated by the serviceassociated with the universal patching machine software), may beperformed manually (e.g., using personnel at the service), or may beperformed using a combination of manual and automatic procedures. Aftervulnerabilities have been identified that are to be patched, networkpatches for the vulnerabilities may be created at step 102. The networkpatch creation process typically involves at least some manual codingoperations that are performed based on an analysis of the vulnerabilityand appropriate solutions to overcome the vulnerability. The networkpatches that are created may be stored on a server associated with anetwork patching service provider and may be distributed to customers atvarious networks 12 over communications network 22.

At step 104, it is determined which of the network patches are needed todetect and fix the vulnerabilities in a given network 12. In particular,manual and or automatic software-based services may be used to gathernetwork status information for the given network 12. The software-basedservices used at step 104 may include a discovery application that scansthe equipment of the given network 12 to determine which vendor patcheshave been installed and which network patches have been installed.

The network status information gathered at step 104 may includeinformation on which vulnerabilities need to be addressed. If desired, asystem administrator at the network 12 may be provided with anopportunity to manually intervene in the processes of deciding whichvulnerabilities need to be addressed. The system administrator may, asan example, decide which network patches to install by clicking onappropriate on-screen options provided by the network patching software.The network patching software used to gather this information may beimplemented using network appliance 18 or any other suitable platform.

Using information on which network patches are available, which vendorpatches have already been installed (so that corresponding networkpatches are not needed), and which vulnerabilities the systemadministrator desires to patch, the patching system software determineswhich network patches are to be included in patching machine 20 andwhich are to be removed from patching machine 20 (e.g., because they areduplicative of installed vendor patches or because the systemadministrator does not desire network patches for particularvulnerabilities).

After the appropriate network patches to be incorporated into theuniversal patching machine 20 have been identified at step 104, thehelper functions of patch processor configuration data 32 may be used tocreate the universal patching machine 20 (step 106). In particular, thehelper functions may merge the state machine logic 84 of the appropriatenetwork patches to form a unified state machine, as described inconnection with FIGS. 7-11. During step 106, the state machines 84 andassociated functions 86 for the selected network patches are mergedwhile duplicative processing capabilities are eliminated.

At step 108, the selected network patches are applied by the universalpatching machine 20 without disrupting the data traffic through networkappliance 18. Any suitable technique may be used to ensure that datatraffic is not disrupted during the network patch update process. Forexample, the new set of network patches may be applied by using a newstate machine to handle new data traffic sessions while an old versionof the state machine is used to handle existing data traffic sessions.As another example, the time at which to apply the new set of networkpatches may be chosen so that the changeover between the old set ofnetwork patches and the new set of network patches does not affectexisting traffic.

As indicated by line 110, the process of FIG. 13 may be performedcontinuously, so that the capabilities of the universal patching machineremain up to date as new vulnerabilities are identified.

Because patching operations are performed by the universal patchingmachine 20 without changing operating system or application files (e.g.,DLLs for Windows) on the equipment 14 of network 12, the use ofuniversal patching machine 20 avoids the problems associated withtesting and deploying vendor patches directly on equipment 14. Theuniversal patching machine 20 does not interact with the operatingsystems and applications running on network 12. The network patches ofmachine 20 only affect the state machine of the patch processors 28.Because there are a relatively small number of possible state machineconfigurations, comprehensive testing of the universal patching machine20 is possible. Comprehensive testing of vendor patches is generally notpractical, because the number of different possible combinations ofoperating systems and applications that exist on the various pieces ofequipment 14 in networks such as network 12 is too large.

FIG. 14 illustrates how comprehensive testing of the universal patchingmachine 20 is possible. In the example of FIG. 14, there are fournetwork patches NP1, NP2, NP3, and NP4. Each network patch 82 contains anumber of state machines 84. As shown in FIG. 14, there is an overlapbetween network patches, so that some of the state machines 84 arecommon to multiple network patches. In the situation of FIG. 14, forexample, there are two state machines 84 in common between network patchNP1 and network patch NP4.

Because not all network patches 82 have state machines 84 in common, itis not necessary to test the operation of all possible combinations ofnetwork patches. For example, when adding network patch NP3 to auniversal state machine made up of network patches NP2, NP1, and NP4, isnot necessary to test the operation of all possible combinations of NP1,NP2, NP3, and NP4. Rather, because the NP3 state machines overlap onlywith the state machines of network patch NP2, it is sufficient to testthe operation of network patch NP3 alone and in any combination ofnetwork patches including NP2. By restricting the testing of networkpatch combinations to only those that are necessary as determined bystate machine overlap considerations, comprehensive testing of theuniversal patching machine is possible. In most situations, the numberof configurations that need to be tested to provide comprehensivetesting is less than ten.

Because the universal patching machine 20 is based on a merged statemachine (see FIG. 9), duplicate processing is avoided. The patchprocessors only execute the state machine logic contained in the mergedstate machine. Because the state machine logic is compressed (merged),it may achieve results efficiently.

By updating the network patches being used to reflect changes inidentified vulnerabilities and installed vendor patches, old networkpatches can be removed. Extraneous processing associated with these oldnetwork patches is therefore eliminated.

Not all packets in the data traffic contain information that is neededto process currently known vulnerabilities. To enhance performance, thepacket controller 26 can forward certain packets at low layers in thenetwork protocol stack as described in connection with FIGS. 5 and 6. Ina typical deployment, more than 90% of traffic need not be sent to patchprocessors 28 and can be forwarded to the patching machine output by thepacket controller 26 at either the IP layer or TCP layer.

The amount of traffic that is processed depends on the number of networkpatches that are needed. As the number of patch processors and networkpatches decreases, the patch configuration data 32 (FIG. 4) reflects thereduced amount of patching to be performed. As a result, the packetcontroller 26 will forward a relatively larger fraction of traffic tothe patching machine output at low network layers without sending it tothe patch processors 28 for vulnerability violation detection and fixingoperations. This is advantageous because it allows the complexity of thepatching machine 20 to be reduced.

Once a vulnerability has been fixed by the universal patching machine20, computer worms and other attacks that attempt to exploit thevulnerability become ineffective.

The foregoing is merely illustrative of the principles of this inventionand various modifications can be made by those skilled in the artwithout departing from the scope and spirit of the invention.

1. A method for protecting a computer network by using a universalpatching machine implemented on a network appliance to detect and fixvulnerability violations in data traffic flowing through the networkappliance between a communications network and the computer network,wherein the universal patching machine includes patch processors and apacket controller, the method comprising: forming the patch processorsin the universal patching machine from a plurality of network patches;receiving the data traffic with the universal patching machine; usingthe patch processors to detect vulnerability violations in the receiveddata traffic; when a vulnerability violation is detected in the datatraffic by the patch processors, using the patch processors to issue amodification command to the packet controller that directs the packetcontroller to fix the data traffic and remove the vulnerabilityviolation; and using the universal patching machine to provide the fixeddata traffic to the computer network.
 2. The method defined in claim 1further comprising: identifying vulnerabilities that need networkpatching before forming the patch processors; and determining whichnetwork patches are needed by the patch processors to detect and fix theidentified vulnerabilities, wherein forming the patch processors in theuniversal patching machine comprises forming the patch processors in theuniversal patching machine from the network patches needed to detect andfix the identified vulnerabilities.
 3. The method defined in claim 1wherein each network patch comprises state machine logic and functionsthat detect and fix the vulnerability violations and wherein forming thepatch processors comprises merging the state machine logic from aplurality of network patches to form a unified state machine.
 4. Themethod defined in claim 3 wherein merging the state machine logiccomprises eliminating duplicative state machine logic when forming theunified state machine.
 5. The method defined in claim 1 wherein eachnetwork patch comprises state machine logic, the method furthercomprising fixing the data traffic to remove the vulnerabilityviolations while using new network patch state machine logic for newsessions in the data traffic and old network patch state machine logicfor old sessions in the data traffic.
 6. The method defined in claim 1further comprising updating the universal patching machine withoutdisrupting the flow of the data traffic by selecting a point in time atwhich to apply a new set of network patches with the universal patchingmachine that does not disrupt the flow of the data traffic.
 7. Themethod defined in claim 1 wherein the universal patching machineoperates on the data traffic at multiple network layers, the methodfurther comprising using the patch processors to process the datatraffic at network layers 6 and
 7. 8. The method defined in claim 1wherein the packet controller operates on the data traffic at multiplenetwork layers, the method further comprising using the packetcontroller to process the data traffic one or more network layers belownetwork layer
 5. 9. The method defined in claim 1 wherein the patchprocessors and packet controller operate on the data traffic at multiplenetwork layers, the method further comprising using the patch processorsto process the data traffic at network layers 5, 6, and 7 and using thepacket controller to process the data traffic at one or more networklayers below network layer
 5. 10. The method defined in claim 1 furthercomprising using the universal patching machine to determine at networklayer 3 whether to forward the data traffic to the computer networkwithout processing by the patch processors or whether to route the datatraffic to the patch processors to detect vulnerability violations. 11.The method defined in claim 1 wherein a client computer is connected tothe communications network and wherein the computer network includes aserver, the method further comprising using the packet controller todetermine whether to forward the data traffic without processing by thepatch processors by determining whether the data traffic is destined tothe client computer or to the server.
 12. The method defined in claim 1wherein the patch processors and packet controller operate on the datatraffic at multiple network layers, the method comprising: identifying ablock of data traffic that is to be forwarded without processing by thepatch processors at network layers 6 and 7; specifying a start locationand block size for the block of the data traffic that is to be forwardedwithout processing by the patch processors at network layers 6 and 7;and forwarding the block of the data traffic to the computer networkwithout processing by the patch processors at network layers 6 and 7.13. The method defined in claim 1 wherein the patch processors andpacket controller operate on the data traffic at multiple networklayers, the method comprising: identifying a block of data traffic thatis to be forwarded without processing by the patch processors at networklayers 6 and 7; specifying an ending pattern for the block of the datatraffic that is to be forwarded without processing by the patchprocessors at network layers 6 and 7; and forwarding the block of thedata traffic to the computer network without processing by the patchprocessors at network layers 6 and
 7. 14. The method defined in claim 1wherein the computer network comprises a plurality of computers andwherein at least one of the computers in the computer network has aninstalled vendor patch, the method comprising using the packetcontroller to forward at least some of the data traffic that is destinedto the computer with the installed vendor patch to that computer withoutprocessing by the patch processors.
 15. The method defined in claim 1wherein the modification command directs the packet controller to changeat least one byte in the data traffic, the method further comprisingusing the packet controller to fix the data traffic by changing the bytein the data traffic in response to the modification command.
 16. Themethod defined in claim 1 wherein the universal patching machineincludes machine code helper functions and wherein forming the patchprocessors comprises using the machine code helper functions to mergestate machine logic from the plurality of network patches to form aunified state machine.
 17. The method defined in claim 1 wherein theuniversal patching machine includes packet controller configurationdata, the method further comprising using access policies in the packetcontroller configuration data to instruct the packet controller whetherto route the data traffic to the patch processors or to output the datatraffic from the universal patching machine without processing by thepatch processors.
 18. The method defined in claim 1 further comprisingusing IP address and port information in determining whether the packetcontroller routes the data traffic to the patch processors or outputsthe data traffic from the universal patching machine without processingby the patch processors.